Summary

• This work is behind a feature toggle (flipper): YES/NO

This pull request reverts the use of a custom error class in the Eps::AppointmentService, which turned out to be interfering with the already present and abstracted error handling in the parent base service. I discovered the bug as I was adding unit tests for upstream failures which in turn verify that the appropriate response is propagated as interpreted from the existing error handling logic.

Related issue(s)

• current ticket: Link to ticket created in va.gov-team repo OR screenshot of Jira ticket if your team uses Jira
• related ticket: Link to previous change of the code/bug (if applicable)

Testing done

• New code is covered by unit tests

What areas of the site does it impact?

Error handling changes:

• modules/vaos/app/services/eps/appointment_service.rb: Removed generic rescue block to avoid swallowing exceptions and to let them propagate properly.
• modules/vaos/app/sidekiq/eps/eps_appointment_worker.rb: Changed the rescue block to handle Common::Exceptions::BackendServiceException instead of Eps::AppointmentService::ServiceError and updated the error message sent to users.

Test additions:

• modules/vaos/spec/requests/vaos/v2/eps_appointments_spec.rb: Added new contexts to test 404 and 500 error responses when fetching EPS appointments.
• modules/vaos/spec/services/eps/appointment_service_spec.rb: Updated test to expect Common::Exceptions::BackendServiceException instead of Eps::ServiceError.
• modules/vaos/spec/sidekiq/eps_appointment_worker_spec.rb: Added new contexts to test error handling for 404 and 500 error responses and updated the expected failure messages. [1] [2]

VCR cassette updates:

• spec/support/vcr_cassettes/vaos/eps/get_appointment/404.yml: Added new VCR cassette to record 404 error response for fetching EPS appointments.
• spec/support/vcr_cassettes/vaos/eps/get_appointment/500.yml: Added new VCR cassette to record 500 error response for fetching EPS appointments.

Acceptance criteria

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No error nor warning in the console.
• Events are being sent to the appropriate logging solution
• Documentation has been updated (link to documentation)
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Feature/bug has a monitor built into Datadog (if applicable)
• If app impacted requires authentication, did you login to a local build and verify all authenticated routes work as expected
• I added a screenshot of the developed feature

Requested Feedback